home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11333 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.3 KB  |  111 lines
  1. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  2. Path: alexandria.organon.com!alexandria!jsa
  3. From: jsa@organon.com (Jon S Anthony)
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. In-Reply-To: kcline@sun152.spd.dsccc.com's message of 12 Mar 1996 11:32:18
  6.     -0600
  7. Message-ID: <JSA.96Mar13180925@organon.com>
  8. Sender: news@organon.com (news)
  9. Organization: Organon Motives, Inc.
  10. References: <JSA.96Feb16135027@organon.com> <adaworksDnrqsE.LpC@netcom.com>
  11.     <4hhred$1rn@sun152.spd.dsccc.com> <4i19mg$vkt@azure.dstc.edu.au>
  12.     <4i4cf2$crm@sun152.spd.dsccc.com>
  13. Date: Wed, 13 Mar 1996 23:09:25 GMT
  14.  
  15. In article <4i4cf2$crm@sun152.spd.dsccc.com> kcline@sun152.spd.dsccc.com (Kevin Cline) writes:
  16.  
  17.  
  18. > I wasn't trying to place blame; I'm trying to explain to Ada
  19. > advocates why most PC and UNIX software developers were (and still
  20. > are) uninterested in Ada, despite the well-known pitfalls in C
  21. > development.
  22.  
  23. Too bad your information is out of date, no longer true, and basically
  24. irrelevant to the situation today.
  25.  
  26.  
  27. > In fact there were several serious flaws in the Ada-83 language that
  28. > made development of hosted applications in Ada-83 more difficult
  29. > than developing them in C or C++.
  30.  
  31. I don't know if I believe this either.  But let's suppose it is true.
  32. What has that to do with Ada95 and here now in 1996?
  33.  
  34. > in fixing their bugs.  This was yet another reason not to use Ada.
  35.  
  36. I'd say that was a reason not to use that vendor.  If there were no
  37. other vendors then _that_ would be a reason to not use Ada.  Or if
  38. you were just plain pissed about it.  Nevertheless, the operative
  39. word in this snippet is "was".
  40.  
  41.  
  42. > There never seemed to be enough licensees to allow the compiler
  43. > vendors to create a decent product in the early 90's; has this
  44. > changed, or will GNAT be the only game in town?  That's not
  45. > necessarily bad; I like public-domain software.  
  46.  
  47. Baloney.  The DEC Ada compiler was one of the best compilers for any
  48. language.  I suppose you meant to qualify that with PC or some such.
  49. And sure, the situation has changed from 5 years ago.  Is the C++
  50. compiler market still just as full of abysmally incompetent,
  51. incompatible and otherwise useless products as in 1990?
  52.  
  53.  
  54. > Emerging? Available soon?  MOTIF is eight years old; X ten.  
  55. > While the Ada community has been trying to reach consensus on
  56. > an X windows/MOTIF binding, the UNIX community has invented
  57. > and widely adopted a whole new language (Tcl/Tk) for GUI development
  58.  
  59. Tcl?  That would be at the bottom of the list.  But again, this is
  60. irrelevant.  You can always just use Ada.Interfaces.C and get the
  61. same as with C.  So, what is your point?
  62.  
  63.  
  64. > Rightly or wrongly, many new software systems are designed initially
  65. > with C and C++ APIs.  It seems doubtful that the Ada community will
  66. > ever grow large enough to be able to produce and standardize on 
  67. > Ada language bindings to new systems in a timely manner.
  68.  
  69. First, you can get at the C stuff just as easily as C can with
  70. Ada.Interfaces.C.  So, who cares about this part?  Second, C can't get
  71. into C++ any better than Ada, unless the C++ specifically extern C's
  72. everything - at which point you can get at it just as easily with
  73. Ada.Interfaces.C.  Actually, the situation is better in Ada as SGI
  74. and others have shown.  So, what's your point?
  75.  
  76.  
  77. > I agree; within five years I predict the DoD mandate will be quietly
  78. > repealed (or largely ignored) and Ada will go the way of APL.
  79.  
  80. Yes, and so will EIffel, SmallTalk, Fortran, etc.  And the god of
  81. C/C++ will rule.  Well, I don't think this will happen and I have a
  82. certain amount of faith that not everyone is as uninformed as you
  83. appear to be.
  84.  
  85.  
  86. > >Note that the CORBA standard language bindings for Ada are expected to be
  87. > >formally approved at the OMG board meeting that happens on March 20th (for
  88. > >memory)
  89. > >
  90. > 
  91. > I hope they are better than the abominable C++ bindings.
  92.  
  93. As I have tried to explain to you before, the Ada/IDL mapping was
  94. considered by many in OMG to be by far the most complete and clean
  95. of any so far specified.  With respect to C++, this is in large
  96. measure because Ada95 is just so much cleaner than C++.  There are
  97. entire sections in the C++ mapping covering issues that have no
  98. relevance whatsoever to Ada.  We were all happy to not have to
  99. deal with any of that rubbish.
  100.  
  101. /Jon
  102. -- 
  103. Jon Anthony
  104. Organon Motives, Inc.
  105. 1 Williston Road, Suite 4
  106. Belmont, MA 02178
  107.  
  108. 617.484.3383
  109. jsa@organon.com
  110.  
  111.